-
Notifications
You must be signed in to change notification settings - Fork 141
Adding nginx_proxy access_log format ability #4102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4102 +/- ##
==========================================
+ Coverage 86.09% 86.14% +0.04%
==========================================
Files 131 131
Lines 14171 14193 +22
Branches 35 35
==========================================
+ Hits 12200 12226 +26
+ Misses 1767 1764 -3
+ Partials 204 203 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
0923130 to
3d18022
Compare
253e3be to
b68f73f
Compare
b68f73f to
74bb187
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API definition feels a bit confusing - as we are only supporting a single log format and a single path, we should simplify the API.
The two-level structure (NginxLogFormat + NginxAccessLog) creates indirection:
- Users define a format with a name
- Then reference that name in accessLog
- This can lead to misconfiguration (mismatched names)
- Both LogFormat AND AccessLog must be set for anything to work
I think we can remove the NginxLogFormat type completely and change the Format field in NginxAccessLog to specify the format string directly. We don't need to provide a mechanism for the user to specify the name of the log format, we can define that as an internal string.
Something like:
type NginxAccessLog struct {
// Disabled turns off access logging when set to true.
// +optional
Disabled *bool `json:"disabled,omitempty"`
// Format specifies the custom log format string.
// If not specified, NGINX default 'combined' format is used.
// See https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format
// +optional
Format *string `json:"format,omitempty"`
}
Later, if we decide to support different path types (e.g. syslog) we can extend this type to add the path field.
Then, if the access log format is set the template renders something like:
log_format ngf_default '<user-format>';
access_log /dev/stdout ngf_default;
And if it's disabled,
access_log off;
Otherwise we can omit the directive, and NGINX will use the default /dev/stdout combined (same behaviour as we have currently)
Does that make sense?
74bb187 to
aadd4f6
Compare
aadd4f6 to
f768d25
Compare
f768d25 to
a0ba554
Compare
865c794 to
85cdb55
Compare
|
Looks pretty good, good job! We should also add the new fields to the Helm schema https://github.com/nginx/nginx-gateway-fabric/blob/main/charts/nginx-gateway-fabric/values.yaml#L451 |
Proposed changes
Problem: As a user of NGF
I want to have the ability to configure the log format of NGINX's access and error logs
So that I can easily collect logs from NGINX in my logging platform.
Solution: Adding accessLog.Disabled and accessLog.Format fields to nginx-proxy CRD, also adding default values for them
Testing:
Tested with custom format:
result:

config uses
/dev/stdoutand default format name:work:

Tested with turning logs OFF:
result:

config has only
offwithout custom log_format:Closes #1200
Checklist
Before creating a PR, run through this checklist and mark each as complete.
Release notes
If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.